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Abstract - The NASA Real Time Mission Monitor (RTMM) is a 
situational awareness tool that integrates satellite, airborne and 
surface data sets; weather information; model and forecast outputs; 
and vehicle state data (e.g., aircraft navigation, satellite tracks and 
instrument field-of-views) for field experiment management. 
RTMM optimizes science and logistic decision-making during 
field experiments by presenting timely data and graphics to the 
users to improve real time situational awareness of the 
experiment's assets. The RTMM is proven in the field as it 
supported program managers, scientists, and aircraft personnel 
during the NASA African Monsoon Multidisciplinary Analyses 
experiment during summer 2006 in Cape Verde, Africa. The 
integration and delivery of this information is made possible 
through data acquisition systems, network communication links 
and network server resources built and managed by collaborators 
at NASA Dryden Flight Research Center (DFRC) and Marshall 
Space Flight Center (MSFQ. RTMM is evolving towards a more 
flexible and dynamic combination of sensor ingest, network 
computing, and decision-making activities through the use of a 
service oriented architecture based on community standards and 
protocols. 

i. Introduction 

The Real Time Mission Monitor (RTMM) is a 

situational awareness, decision-support system that 
integrates satellite remote sensing, aircraft position 
and weather state information, airborne and surface 
instrument observations for Earth science research 
investigators. The integration and delivery of this 
information is made possible through data acquisition 
systems, network communication links, and network 
server resources built and managed by the authors at 
the NASA Marshall Space Flight Center (MSFC) and 
the NASA Dryden Flight Research Center (DFRC). 

The RTMM integrates satellite and radar 
imagery, surface and airborne instrument data sets, 
model output parameters, lightning location 
observations, aircraft (including balloon) navigation 
data, soundings (e.g., dropsonde), and other 
applicable Earth science data sets. The RTMM uses 


the Google Earth application as the user 
visualization. 

The genesis of RTMM dates back about a decade 
at NASA MSFC and NASA DFRC. Both groups 
independently developed methods to better ingest, 
process, and distribute aircraft and instrument data in 
support of NASA Earth science field campaigns. The 
RTMM, developed at MSFC, builds upon the solid 
heritage of earlier mission and weather monitor 
applications implemented during the 2002 Altus 
Cumulus Electrification Study [1] and other airborne 
and ground-based missions. An interactive Java- 
based web prototype emerged in mid-2005 and was 
used to support the Lightning Instrument Package 
(LIP) during the Tropical Cloud Systems and 
Processes (TCSP) campaign in Costa Rica [2]. This 
prototype RTMM was primarily used by the LIP 
instrument team with only ancillary use by other 
scientists in TCSP. However, it was during the 2006 
NASA African Monsoon Multidisciplinary Analyses 
(NAMMA) field experiment in the Cape Verde 
Islands off the coast of Senegal in West Africa when 
the widespread use of RTMM by multiple instrument 
scientists, mission scientists, and program managers 
was fully realized. In anticipation of its broader user- 
base with NAMMA science operations, the RTMM 
was redesigned to utilize Google Earth and its 
constituent Keyhole Markup Language (KML) as an 
integration interface for real-time displays. What 
emerged from these iterative improvements was the 
capability to leverage a single, easy to use 
visualization tool that supports science and logistics 
decision-making by merging disparate and 
geographically distributed information that is 
constantly changing. Behind the scenes, we designed 
a sustainable infrastructure able to grow and support 
virtually any airborne science campaign, anywhere, 
anytime. 


A key addition and advanced capability added 
during NAMMA was providing, for the first time, a 
local RTMM capability on the DC-8 aircraft itself 
during the flights. This provided on-board scientists 
and aircraft operators access to imagery and data sets 
unavailable in prior airborne campaigns. 

Figure 1 illustrates how airborne and ground- 
based network resources are tied together to create a 
sub-orbital tele-presence that constitutes the 
beginnings of a sub-orbital sensor web. The 
bidirectional transmission of data and information 
between the aircraft and redundant RTMM servers 
are made possible through a dynamically 
configurable embedded data system and network 
gateway called the Research Environment for 
Vehicle Embedded Analysis on Linux (REVEAL) [3] 
developed by the NASA Dryden Flight Research 
Facility. REVEAL connects to the network using 
Iridium satellite data links. 

The existing core functionality of RTMM 
enables any user with internet access (e.g., at the 
NAMMA mission operations center in Cape Verde, 
aboard the NASA DC-8 aircraft, or at a remote site 
back in the United States) to monitor - in real-time - 
multiple field observation assets including but not 
limited to multi -spectral geostationary satellite 
imagery (e.g., GOES, Meteosat), polar orbiting 
satellite tracks and instrument field of views (e.g., 
NASA satellites and instruments), derived NASA 
satellite products (e.g., AMSR-E sea surface 
temperatures), surface weather radar, global lightning 
observations, radiosondes and dropsondes, aircraft 
flight tracks, airborne instrument observations aboard 
the DC-8, and forecast model output parameters. All 
of these data sources were utilized during the 
NAMMA field campaign. 

Figure 2 depicts some of the observations during 
a NAMMA flight on 12 September 2006 off the coast 
of West Africa. The NASA DC-8 is sampling a 
tropical depression that is the precursor to Hurricane 
Helene. In the figure, the airplane icon represents the 
current position of the NASA DC-8 as it follows the 
planned flight track (green “figure-8”). The actual 
aircraft track is represented by the red line which for 
the most part is following the green pre-planned 
flight track. Another feature to note is the broad red 
swath oriented southwest to northeast which 
represents the track of the TRMM satellite with the 1- 
minute field-of-view of TRMM Microwave Imager 
overlaid in green. 


Figure 1. Airborne and ground-based network 
resources linked together to form a sub-orbital 
sensor web. 

These graphics are superimposed upon a 
background image of a color enhanced infrared 
Meteosat image. Cloud-to-ground lightning strikes 
are denoted by the yellow cross hatching embedded 
in the most intense convection within the storm. 
Along the red aircraft flight track can be seen red flag 
markers depicting the location of dropsondes that 
were deployed from the DC-8. Another feature to 
note is the aircraft altitude graph in the upper left 
comer. The strength of RTMM is its ability to 
continually provide the user with animated satellite, 
aircraft flight level and surface state information. 
Although Fig. 2 is a still photographic image, a 
wealth of information is readily conveyed in a 
concise and easy-to-use interface. It is important to 
remember that all these data sources and information 
are integrated in near real-time and presented to the 
end-user. The animated geostationary satellite 
images are updated every 1 5-minutes while the other 
observations described above are continuously 
updated to enhance situational awareness and 
optimize the scientist’s decision making capabilities. 
To see an animated view of past airborne missions 
please go to the RTMM home page at 
http://rtmm.nsstc.nasa.gov. 
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Figure 2. Screen shot of Real-time Mission Monitor of the NAMMA DC-8 flight on 12 September 2006 off the 
West African coast. 


II. RTMM Architecture and Interface 
Standards 

From a user’s perspective the Real Time Mission 
Monitor seamlessly integrates multiple data sources 
into a single interface. The RTMM is built upon a 
loosely-coupled, Web-based, service oriented 
architecture (SOA). The term loosely-coupled 
implies that the service client is independent of the 
service. The client doesn’t have to know a priori the 
details of the service provider (e.g., the service 
platform, operating system, or language). A Web- 
based SOA is predicated upon a well defined set of 
interface standards and protocols that enable 
interoperability between the component pieces. As 
previously noted, the RTMM utilizes uses Google 
Earth’s client to display an integrated set 
environmental parameters to the viewer. Google 
Earth incorporates the KML standard to define 
where, when, and how often to gather the data and 
information into the service. These data are created 
and/or ingested at MSFC and placed on servers 
accessible by the end-user. 

The RTMM data are accessible by a standard 
Apache web server to the client’s Google Earth 
display using the HTTP protocol. A large number of 


software packages run on the distributed RTMM 
servers to provide these data (Fig. 3). The servers 
may be located at both ground and/or airborne sites. 
These data packages ingest satellite, lightning, radar, 
navigation, and dropsonde data. The data are 
processed and converted to a form that is compatible 
with the Google Earth display software (e.g., PNG 
images geolocated in a cylindrical equal-angle 
projection). Weather forecast model output 
parameters and other imagery are created by external 
data providers and are downloaded to the RTMM 
servers for visualization by the client. 

As illustrated in Fig. 3, the RTMM user may be 
located on the (upper left) ground or in the air aboard 
an aircraft (e.g., the NASA DC-8; lower right). The 
RTMM user invokes Google Earth using a predefined 
KML file. After initiating the RTMM, the user can 



exercise full control over the data sets selected. 
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Figure 3. A distributed network architecture in a 
typical RTMM field deployment. Data acquisition 
servers can be located at remote locations including 
aircraft and field operations sites. Communications 
between the airborne servers and the surface 
servers is provided by the REVEAL network 
gateway. 

The RTMM also provides an exciting new 
capability to review data previously captured. The 
user selects a date/time range and playback speed 
(e.g., review 5-minutes of flight time per ~2-sec 
interval of current time) and then animates the 
selected data sets in a fast forward mode. The 
playback capability enables any user to interrupt a 
real-time visualization and dynamically review an in- 
flight sequence and then resume the real-time 
viewing. Another use of playback is to review a 
completed mission in post-mission analyses. An 
example of this feature is demonstrated in a review of 
a NAMMA flight mission months after it was 
completed. In this NAMMA review scenario, the 
user selects the flight day and can playback the entire 
6-hr mission in a few minutes by adjusting the 
playback speed, accordingly. Throughout the 
playback, the individual data sets (e.g., infrared and 
visible satellite channels, cloud-to-ground lightning, 
airborne instrument observations, etc.) collected on a 
flight day can be dynamically turned on/off for 
viewing. 


III. New Services and Functionality 


navigation ephemeris (two-line element sets) to 
produce the satellite tracks and associated instrument 
field-of-views. Adding functionality necessitates that 
we meet the complex challenge of automating the 
integration of data from multiple sensors, platforms, 
and models by implementing a sensor web enabled 
environment with common protocols and formats. 
The SWE protocols enable dynamic discovery and 
access of data and information. The suite of sensor 
web standards and protocols enable heterogeneous 
plug and play operations. Within the SWE 
framework, there is little distinction between an 
instrument, model and simulation, and data 
processing engine. They all are termed “sensor 
systems” and can be described in SensorML as 
process models or chains. As sensor systems, they all 
produce observations that can encoded in the 
Observations & Measurements specification and be 
advertised and accessed through a SOS. Many of 
these sensor systems can also be tasked or configured 
to meet the specific needs of the user and are thus 
candidates for web enablement through the Sensor 
Planning Service. We anticipate incorporating sensor 
web services to connect RTMM visualizations to data 
access. 


IV. Conclusion 

The RTMM is a situational awareness tool that was 
proven in the field as a mission essential asset during 
the NAMMA campaign. The RTMM enabled 
NAMMA airborne scientists and ground-based 
science operations and program managers to 
simultaneously have access to flight status 
information in order to facilitate mission execution. 
The RTMM supports mission planning and mission 
coordination and execution through the inclusion of 
weather forecast model output parameters, aircraft 
waypoint tracks, and predicted satellite nadir track 
and instrument field-of-views.. Post-mission 
analyses are aided by playback capabilities. The 
RTMM development effort represents an 
evolutionary step toward a general set of “sensor 
web” and “intelligent airborne observation system” 
capabilities targeted by Earth science technology 
insertion investments. 


We are adding functionality to RTMM by 
employing services that use the Open Geospatial 
Consortium (OGC) Sensor Web Enablement (SWE) 
environment [4]. Using a Sensor Observations 
Service (SOS), the RTMM accesses an historical 
tropical storm database that describes the location, 
date, time, and intensity of the storms. Another 
sensor web enabled service uses the Sensor Model 
Language (SensorML) to processes the satellite 
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